Setting the `package.workspace` key in child workspace fails splicing
with an error similar to

```
Found manifest at /home/mlaurin/src/check_mk.git/packages/site/check-http/Cargo.toml which is a member of the workspace at
/home/mlaurin/src/check_mk.git/packages/site/check-http/.. which isn't included in the crates_universe
```

Now, the key is valid in Cargo.toml when the code is organized in
workspaces.  It is even required for out-of-tree workspaces.  See
https://github.com/nox/rust-rfcs/blob/master/text/1525-cargo-workspace.md

Before December, the key was ignored but would not fail splicing.  The
regression is most likely due to changes related to
bazelbuild#3090

Library to normalize path without symlink resolution.

The trivial `PathCleanUtf8` trait mimics the `Clean` trait implemented
for `PathBuf` in the `clean_path` library.

https://docs.rs/clean-path/latest/clean_path/trait.Clean.html

Change all `crate_universe.html` -> `crate_universe_workspace.html` to
fix a few 404 in the docs.

I did some experiments on [this
example](https://github.com/bazelbuild/rules_rust/blob/e38fa8c2bc0990debceaf28daa4fcb2c57dcdc1c/examples/hello_world/MODULE.bazel#L25-L30)
to evaluate the `lockfile` attribute vs. using `MODULE.bazel.lock`:

I ran `bazel test //... --profile=...`. After every run, I did a `bazel
clean && bazel shutdown` to start clean.

1. Run (`MODULE.bazel.lock` file only): No `cargo-bazel` call found in
the profile generated
1. Run (add the `lockfile`, run `CARGO_BAZEL_REPIN=true bazel mod tidy`,
then `bazel test`): No `cargo-bazel` call found in the profile generated
1. Run (delete `MODULE.bazel.lock`): `cargo-bazel` was called, but cargo
splicing was very fast. The `MODULE.bazel.lock` was recreated
1. Run (delete`MODULE.bazel.lock` and run with `--lockfile_mode=off`):
`cargo-bazel` was called, similar to above

This suggests:

* If you have the `MODULE.bazel.lock` file up to date, no `cargo-bazel`
is called regardless of using the `lockfile` or not
* If the `MODULE.bazel.lock` is not tracked in VCS the `lockfile` seems
to be helpful and should be used
* Comparing the `MODULE.bazel.lock` file and the `lockfile` a bit more
in detail, shows they store similar information. The `lockfile` is a bit
more well structured json (for the rust specific content) while the
`MODULE.bazel.lock` file seems to store the entire content generated for
every crate in a single string.

The code removed here assumes that members are necessarily in
subdirectories of the cargo workspaces.  This is incorrect as
cargo handles out-of-tree workspaces.

Moreover, the last loop of the function populates the
`non_workspaces` structure.

This patch adds handling for out-of-tree workspaces.  The feature is
supported by cargo and requires that the root workspaces declare its
members in the key
```
[workspace]
members = [
   <RELATIVE_PATH_TO_MEMBERS>
]
```
and the members point back to the root workspace with the
following declaration:
```
[package]
workspace = <RELATIVE_PATH_TO_ROOT>
```

This patch complements the discovery by handling the members (in- or
out-of-tree) explicitly if the cargo manifests features the entries
mentioned above.

Closes bazelbuild#3450

* Take `exclude` list into account during discovery
* Return `None` for workspace_prefix if it is empty